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ABSTRACT 


A  study  of  SONET  network  management  applications  and  the  load  they  impart  to 
the  network  is  conducted  to  provide  a  better  understanding  of  the  capability  of  various 
management  approaches.  In  this  study,  a  SONET  network  is  set  up  in  the  Advanced  Net¬ 
working  Eaboratory  of  the  Naval  Postgraduate  School  using  four  Cisco  ONS  15454s. 
Next,  two  Element  Management  Systems,  the  Cisco  Transport  Controller  and  the  Cisco 
Transport  Manager,  are  deployed  onto  the  SONET  network.  Subsequently,  the  network 
traffic  of  the  Element  Management  Systems  is  captured  and  analyzed  using  a  packet  ana¬ 
lyzer.  Eink  utilization  of  the  two  tools  is  computed  using  the  first-order  statistics  of  the 
captured  traffic  distributions.  In  addition,  the  Hurst  parameter  is  estimated  using  the  vari¬ 
ance-index  plot  technique  (which  uses  higher-orders  statistics  of  the  modeled  distribu¬ 
tions)  to  determine  the  captured  traffic’s  degree  of  self-similarity.  Einally,  the  calculated 
utilization  is  extrapolated  to  obtain  the  link  utilization  for  2500  network  elements  (the 
maximum  number  supported  by  the  Cisco  Transport  Manager).  The  result  obtained  is 
useful  in  determining  the  maximum  number  of  network  elements  (Cisco  ONS  15454s) 
that  the  Cisco  Transport  Manager  can  support  from  a  network  loading  point  of  view. 
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EXECUTIVE  SUMMARY 


Since  its  introduction  into  telecommunications  networks,  fiber  optie  technology 
has  enabled  the  telecommunications  industry  to  provide  better  quality  of  service  at  huge 
cost  savings  to  consumers.  Subsequently,  optical  standards  such  as  SONET/SDH  were 
proposed  and  adopted  to  ensure  interoperability  between  equipment  of  different  vendors. 
Due  to  popular  demand,  the  size  of  SONET/SDH  networks  has  grown  vastly,  thus  be- 
eoming  increasingly  difficult  to  manage.  Therefore,  it  is  critical  to  have  management 
tools  that  can  interface  with  SONET/SDH  equipment  to  poll  and  aequire  information 
from  conneeted  network  elements  (NEs).  Consequently,  management  overhead  traffic  is 
injected  into  the  network  by  the  respective  management  tools  and  their  eonneeted  NEs. 

In  this  study,  SONET  network  management  applications,  in  particular  Element 
Management  Systems  (EMSs),  and  the  load  they  impart  into  the  network  are  investigated 
to  provide  a  better  understanding  of  the  capability  of  various  management  approaehes.  A 
SONET  network  was  set  up  in  the  Advanced  Networking  Eaboratory  of  the  Naval  Post¬ 
graduate  Sehool  using  four  Ciseo  ONS  15454s. 

During  a  preliminary  market  survey,  it  was  found  that  most  SONET/SDH  equip¬ 
ment  manufacturers  build  their  own  EMS  to  support  their  own  products.  In  addition, 
there  are  few  third-party  EMSs  that  can  interface  with  multi-vendor’s  products.  There¬ 
fore,  the  two  EMSs  deployed  onto  the  Advanced  Networking  Eaboratory’ s  SONET  net¬ 
work  are  the  Cisco  Transport  Controller  (CTC)  and  the  Ciseo  Transport  Manager  4.6 
(CTM  4.6). 

The  CTC  was  set  up  in  the  Cisco  ONS  15454  to  collect  and  monitor  the  NEs  on 
the  SONET  network.  The  NEs’  information  was  collated  at  one  NE  and  forwarded  to  a 
CTC  client  that  was  eonneeted  to  the  NE  through  an  Internet  Protoeol  (IP)  network.  The 
same  NE  was  also  eonneeted  to  a  Sun  Solaris  workstation,  whieh  was  configured  with  the 
CTM  4.6  server,  through  the  same  IP  network.  Subsequently,  packet  analyzers  (Ethereal) 
were  deployed  on  the  IP  network  to  passively  eapture  the  network  traffic  inbound  and 
outbound  from  the  CTC  elient  and  the  Sun  Solaris  workstation. 


XV 


In  the  first  round  of  analysis  using  Ethereal,  it  was  revealed  that  both  the  CTC  and 
CTM  4.6  use  a  proprietary  Soeks  protocol  (which  incorporated  General  Inter-Orb  Proto¬ 
col)  that  connects  to  TCP  Port  1080.  The  CTM  4.6  also  uses  SNMP.  Therefore,  the  cap¬ 
tured  traffic  was  divided  into  five  categories:  CTC’s  Socks  traffic,  CTM  4.6’s  Socks  traf¬ 
fic,  CTM  4.6’s  SNMP  traffic,  CTM  4.6’s  Socks  and  SNMP  traffic,  and  CTM  4.6’s 
Ethernet  traffic.  Then  the  categorized  traffic  underwent  a  data  pruning  process  using  Mi¬ 
crosoft  Access. 

Next  the  interarrival  times  and  packet  sizes  of  the  pruned  data  were  analyzed  sta¬ 
tistically  using  Mathcad  and  Micrsoft  Excel  (as  the  plotting  tool).  Using  first-order  statis¬ 
tics,  the  link  utilizations  of  the  five  categories  of  traffic  were  computed  and  linearly  ex¬ 
trapolated  to  obtain  the  link  utilizations  of  the  same  traffic  for  50  NEs  (the  CTC’s  capac¬ 
ity)  and  2500  NEs  (the  CTM  4.6’s  capacity).  The  results  show  that  the  CTC  will  utilize 
about  1.7%  of  the  Section  Data  Communication  Channel’s  (SDCC)  capacity  of  192  kbps 
when  managing  50  NEs  while  the  CTM  4.6  will  utilize  about  93%  of  the  SDCC’s  capac¬ 
ity  when  managing  2500  NEs. 

In  addition,  the  Hurst  parameter  for  the  interarrival  time  distributions  and  the 
packet  size  distributions  were  estimated  using  the  variance-index  plot  technique  (which 
uses  higher-orders  statistics)  to  determine  the  degree  of  self-similarity.  The  results  show 
that  the  CTC’s  traffic  has  a  high  degree  of  self-similarity  while  the  CTM  4.6’s  traffic  re¬ 
sembles  M/M/1  traffic  with  a  Hurst  parameter  value  close  to  0.5. 

Einally,  by  plotting  the  mean  network  utilization  versus  the  queue  depth  for  the 
estimated  Hurst  parameters,  utilizations  for  the  CTC  and  the  CTM  4.6  (taking  into  ac¬ 
count  the  burstiness  of  the  CTC  and  CTM  4.6’s  traffic)  were  obtained.  The  results  show 
that,  although  the  CTC’s  traffic  is  self-similar  and  bursty,  the  low  link  utilization  (for 
managing  50  NEs)  requires  a  small  queuing  buffer.  On  the  other  hand,  a  much  larger 
queuing  buffer  is  required  to  support  the  high  link  utilization  of  the  CTM  4.6  (for  manag¬ 
ing  2500  NEs).  Thus  it  is  possible  but  not  advisable  to  use  the  CTM  4.6  for  managing 
2500  NEs.  Instead,  it  is  recommended  to  use  the  CTM  4.6  for  managing  up  to  1027  NEs, 
operating  within  a  link  utilization  of  38%  that  can  be  supported  by  a  relatively  much 
smaller  queuing  buffer. 


XVI 


LIST  OF  SYMBOLS,  ACRONYMS,  AND/OR  ABBREVIATIONS 


Alcatel 

ANSI 

ARP 

AT&T 

CCITT 

Cisco 

CMIP 

CMIS 

CORBA 

CPU 

CTC 

CTM  4.6 

DCC 

EMSs 

Fujitsu 

Gbps 

GIOP 

GUI 

H 

HTTP 

IDs 


Alcatel  Network  Systems 

American  National  Standards  Institute 

Address  Resolution  Protocol 

American  Telephone  and  Telegraph  Company 

International  Telegraph  and  Telephone  Consultative  Committee 

Cisco  Systems 

Common  Management  Information  Protoeol 

Common  Management  Information  Services 

Common  Objeet  Request  Broker  Arehiteeture 

central  processing  unit 

Cisco  Transport  Controller 

Ciseo  Transport  Manager  4.6 

Data  Communication  Channel 

Element  Management  Systems 

Fujitsu  Network  Transmission  Systems 

gigabits-per-second 

General  Inter-Orb  Protoeol 

Graphical  User  Interface 

Hurst  parameter 

Hypertext  Transfer  Protoeol 

Identifications 

xvii 


IETF 

IP 

ISO 

ITU-T 

J2RE 

Java-RMI 

JRE 

kB 

kbps 

log 

Lucent 

M/M/I 

MA 

Mbps 

ms 

NEC 

NEs 

NML-EML 

NMSs 

NFS 

OAM&P 
ONS  15454 
OS 


Internet  Engineering  Task  Foree 
Internet  Protoeol 

International  Standardization  for  Organization 

International  Telecommunication  Union-Telecommunication 
Standardization  Bureau 

Java  2  Runtime  Environment 

Java  Remote  Method  Invocation 

Java  Runtime  Environment 

kilobytes 

kilobits-per-seeond 
logarithmic  function 
Lucent  Teehnologies 

System  with  exponential  interarrival  and  service  times 

Mobile  Agents 

megabits-per-seeond 

milliseconds 

NEC  Transmission 

Network  Elements 

Network  Management  Layer-Element  Management  Layer 
Network  Management  Systems 
Naval  Postgraduate  Sehool 

Operations,  Administration,  Maintenance,  and  Provisioning 
Optical  Network  System  15454 
Operating  System 

xviii 


OSI 

PC 

PM 

q 

s 

SDCC 

SDH 

SNMP 

SNMPv2 

SONET 

TCC+ 

TCP 

TLl 

TMF 

TNS 

Ts 

UDP 

2 

)J,S 

P 


Open  System  Interconneetion 
Personal  Computer 
Performanee  Monitoring 
queue  depth 
seconds 

Section  Data  Communication  Channel 

Synchronous  Digital  Hierarchy 

Simple  Network  Management  Protocol 

Simple  Network  Management  Protocol  Version  2 

Synchronous  Optical  Network 

Timing  Control  Card  Plus 

Transport  Control  Protocol 

Transaction  Language  1 

Telemanagement  Forum 

Oracle’s  proprietary  communications  protocol 

service  time 

User  Datagram  Protocol 

mean  arrival  rate  in  items  per  second 

microseconds 

mean  network  utilization 


XIX 


THIS  PAGE  IS  INTENTIONALLY  LEET  BLANK 


XX 


I.  INTRODUCTION 


A.  MOTIVATION 

Since  the  teleeommunieations  industry  started  using  optieal  fiber  for  their  tele- 
eommunieations  networks  in  the  1980s,  they  have  been  able  to  provide  better  network 
quality  at  a  huge  eost  savings  to  their  customers.  These  benefits  have  generated  substan¬ 
tial  researeh  in  optieal  fiber  technologies  and  ereated  many  advanees  in  optical  networks 
[1]. 

As  the  large-seale  deployment  of  optieal  fiber  began,  the  industry  realized  the 
need  for  an  optical  standard  to  ensure  interoperability  of  optical  equipment  from  different 
vendors  [1].  Using  the  standard  proposed  by  Bellcore,  the  American  National  Standards 
Institute  (ANSI)  introdueed  the  Synehronous  Optieal  Network  (SONET)  standard  in 
1985.  The  International  Telegraph  and  Telephone  Consultative  Committee  (CCITT), 
predeeessor  of  the  International  Teleoommunieation  Union-Teleoommunieation  Stan¬ 
dardization  Bureau  (ITU-T),  modified  Belleore’s  proposal  and  ereated  the  Synehronous 
Digital  Hierarehy  (SDH)  standard  as  the  international  version  of  the  same  teehnology 
[2,3]. 

A  major  feature  of  SONET/SDH  is  its  sealability,  whieh  helps  these  standards 
meet  the  quest  for  higher  network  capaeity  [1].  Both  teehnologies  have  evolved  over  the 
years  to  support  up  to  a  data  rate  of  40  gigabits-per-seeond  (Gbps)  at  the  OC-768  optieal 
level  [3].  SONET/SDH  thus  forms  most  of  the  eore  baekbone  networks  of  the  Internet 
due  to  demand  for  high-speed  network  transmission  used  by  multimedia  applications  and 
bandwidth  consuming  software. 

As  SONET/SDH  networks  grow  in  size,  managing  them  beeomes  inereasingly 
diffieult.  Management  tools  that  ean  interfaee  with  SONET/SDH  equipment  to  eapture 
the  relevant  network  information  are  eritical.  The  usual  management  method  is  to  poll 
and  aequire  information  from  network  elements  (NEs).  In  this  ease,  it  is  likely  that  man¬ 
agement  overhead  traffie  is  injeeted  into  the  network  by  the  respeetive  management  tool 
and  the  NEs.  Therefore,  it  would  be  interesting  to  find  out  the  amount  of  management 
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traffic  injected  into  the  network,  and  to  determine  either  the  optimum  number  of  NEs  or 
the  maximum  number  of  NEs  that  ean  eoexist  on  the  network  before  it  beeomes  overly 
eongested  with  management  traffic. 


B,  THESIS  OBJECTIVE 

The  primary  objeetive  of  this  thesis  was  to  study  and  analyze  the  performance  of 
management  tools,  particularly  Element  Management  Systems  (EMS)  that  are  used  for 
managing  SONET/SDH  networks.  A  SONET  network  was  simulated  under  laboratory 
eonditions  with  EMSs  running.  The  network  load  generated  by  the  different  EMSs  utiliz¬ 
ing  different  eommunication  protocols  were  then  captured  and  analyzed.  The  analysis 
was  done  on  the  packet  size  distribution  and  the  interarrival  time  in  between  packets  dis¬ 
tribution.  The  main  thrust  was  to  model  the  network  load  generated  by  the  EMS  using  the 
eoneept  of  self-similarity  so  as  to  determine  the  optimum  number  of  NEs  that  could  be 
deployed  on  a  single  SONET  network  running  the  EMS,  with  suffieient  buffers  for  the 
payload  traffic  based  on  a  speeific  bandwidth. 

C.  RELATED  WORK 

Network  management  is  an  area  of  great  research  potential.  Many  papers  have 
been  written  on  management  protoeols  like  the  Open  System  Interconnection’s  (OSI) 
Common  Management  Information  Protoeol  (CMIP),  the  Internet  Engineering  Task 
Eoree’s  (lETE)  Simple  Network  Management  Protoeol  (SNMP),  and  distributed  object 
technologies  like  Common  Objeet  Request  Broker  Arehiteeture  (CORBA)  and  Java  Re¬ 
mote  Method  Invoeation  (Java-RMI). 

However,  as  networks  expand,  eollecting  information  about  them  beeomes  an  ex- 
eeedingly  complex  task  for  a  monitoring  teehnique  based  on  either  management  proto¬ 
cols  or  distributed  objeet  technologies.  Reeent  researeh  is  foeused  on  the  potential  of  de¬ 
ploying  Mobile  Agents  (MA)  for  network  monitoring  purposes  [4]. 

Within  the  Naval  Postgraduate  Sehool  (NPS),  the  Advanced  Networking  Labora¬ 
tory  has  been  actively  researching  network  management,  partieularly  SONET/SDH  net¬ 
works.  Reeent  work  by  Kok  Seng  Lim  [5],  whieh  studied  the  effeet  of  SNMP  traffie  on 
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Network  Management  Systems  (NMS),  showed  that  a  NMS  ean  effeetively  manage  a 
network  with  less  than  200  NEs. 

D,  SUMMARY 

This  thesis  is  organized  as  follows:  Chapter  II  diseusses  the  SONET  network 
management  tools  and  the  various  protoeols  used  with  foeus  on  the  Ciseo  Transport  Con¬ 
troller  (CTC)  using  General  Inter-Orb  Protoeol  (GIOP)  and  the  Ciseo  Transport  Manager 
4.6  (CTM  4.6)  using  Simple  Network  Management  Protoeol  Version  2  (SNMPv2).  Chap¬ 
ter  III  deseribes  the  proeedures  for  setting  up  the  laboratory  SONET  network,  the  EMS, 
and  the  eapturing  of  the  network  load  used  in  this  study.  Chapter  IV  briefly  reviews  the 
probability  theory  relevant  to  this  study  and  the  eoneept  of  self-similarity.  Chapter  V  pre¬ 
sents  the  traffie  analysis  done  on  the  eaptured  traffie  and  diseusses  the  results  obtained. 
Chapter  VI  eoneludes  the  study  and  provides  suggestions  on  further  researeh  areas. 
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II.  SONET  NETWORK  MANAGEMENT  TOOLS 


A.  CHAPTER  OVERVIEW 

This  chapter  gives  a  short  introduetion  of  SONET  network  management  tools  and 
produets.  It  then  goes  on  to  briefly  discuss  the  eommon  network  management  protoeols. 
Subsequently,  the  ehapter  focuses  the  reader  on  two  EMSs,  the  CTC  and  the  CTM  4.6. 


B,  INTRODUCTION 

SONET  network  management  involving  operations,  administration,  maintenanee, 
and  provisioning  (OAM&P)  is  provided  for  in  the  SONET  standard  [6].  In  order  to  utilize 
that  eapability  provided  by  SONET,  a  NMS  is  required.  However,  the  NMS  works  only 
at  the  upper  level  and  manages  the  traffie  on  the  network  domain.  It  manages  the  NEs 
through  the  use  of  an  EMS.  “The  role  of  the  EMS  is  to  eontrol  and  manage  all  aspeets  of 
the”  NEs  in  a  network  “domain  and  to  ensure  maximum  usage  of  the  deviees’  resourees.” 
[7]  This  typically  includes  gathering  information  on  the  network  domain  through  interae- 
tion  with  each  NE  and  issuing  commands  to  the  NE. 

Most  SONET  equipment  and  EMS  are  vendor-speeifie.  The  six  main 
SONET/SDH  equipment  manufaeturers  are  Aleatel  Network  Systems  (Aleatel),  Eujitsu 
Network  Transmission  Systems  (Eujitsu),  Eucent  Teehnologies  (Eueent),  NEC  Transmis¬ 
sion  (NEC),  Nortel  Networks,  and  Tellabs  [6].  Aleatel  1353  GEM,  an  EMS  product  by 
Alcatel,  supports  only  Aleatel’s  line  of  NEs  [8].  Similarly,  Eijitsu’s  NetSmart  500  and 
1500  software  are  EMSs  built  to  support  Eujitsu’s  Elashwave  family  of  SONET  equip¬ 
ment  [9].  Eikewise,  Lueent’s  Navis®  Optieal  EMS  supports  only  Lueent’s  optical  NEs 
[10].  In  an  email  eorrespondenee  with  Kazuhiro  Kara  of  NEC,  he  informed  that  NEC 
does  not  have  management  tools  that  support  other  vendors’  products  and  has  no  plans  to 
develop  any  [1 1].  In  the  same  way,  the  Tellabs  7190  Element  Manager  is  built  for  man¬ 
aging  Tellabs’  7000  series  NEs  [12].  The  same  vendors  also  supply  NMSs  to  work  in 
eonjunetion  with  their  EMSs.  Aleatel  and  Eueent’s  NMSs  also  provide  for  multi-vendor 
NEs’  interfaee  through  the  use  of  CORBA  [13,14].  Nevertheless,  there  is  no  published 
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case  study  of  anyone  deploying  SONET  equipment  with  a  NMS  from  different  suppliers. 
The  only  known  ease  is  that  of  the  Ameriean  Telephone  and  Telegraph  Company 
(AT&T),  a  teleeommunications  serviee  provider  eompany  that  utilizes  multi-vendor 
SONET  equipment.  In  an  email  eorrespondenee  with  Herbert  Shulman  of  AT&T,  he 
stated  that  AT&T  develops  the  management  tool  in-house  [15]. 


C.  NETWORK  MANAGEMENT  PROTOCOLS 

Although  eaeh  vendor  builds  their  own  software  system  for  managing  their  own 
SONET  equipment,  standards  with  “speeifieations  that  have  a  eross-system  and  multi¬ 
vendor  orientation”  do  exist  [16].  Over  the  years,  the  International  Standardization  for 
Organization  (ISO)  and  ITU-T  have  been  developing  several  network  management  stan¬ 
dards  based  on  the  OSI  arehiteeture.  These  standards  use  the  eommon  management  in¬ 
formation  serviees  (CMIS)  with  CMIP  as  the  management  protoeol.  The  CMIS/CMIP 
pair  is  quite  eomprehensive,  but  its  eomplexity  in  implementation  partly  renders  it  un¬ 
popular  with  SONET  equipment  vendors  [6]. 

When  SONET  was  first  introduced,  CMIS/CMIP  was  not  an  available  solution  for 
network  management.  The  SONET  equipment  vendors’  only  choiee  was  implementing 
the  transaction  language  1  (TEl).  TEl  was  developed  to  be  a  “man-maehine  language,” 
with  a  human  managing  the  network  through  a  eommand-line  terminal.  Being  vendor- 
neutral  and  easy  to  implement,  TEl  beeame  the  popular  choiee  for  vendors.  Nevertheless, 
it  requires  a  separate  eommunieation  link  to  the  NEs  being  managed.  This  aspeet  and  the 
faet  that  TEl  requires  a  human  in  the  loop  limit  its  usage  in  modern  networks.  [6] 

Subsequently,  the  development  of  the  Internet  saw  another  network  management 
protocol  appearing  on  the  scene.  SNMP,  the  IEEE’s  standard,  was  designed  for  managing 
nodes  on  an  IP  network.  As  the  name  implies,  SNMP  is  simple  and  easy  to  implement. 
Nearly  all  deviees  support  SNMP,  and  numerous  management  applieations  using  SNMP 
are  available.  SNMP  uses  the  “trap”,  whieh  is  essentially  a  message  that  reports  a  prob¬ 
lem  or  event.  The  main  drawbaek  of  SNMP  is  its  use  of  a  connectionless  protoeol,  the 
user  datagram  protoeol  (UDP),  for  eommunieations.  SNMP  version  1  is  the  dominant 

management  protoeol  in  the  data  eommunieation  world.  However,  it  has  eertain  limita- 
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tions  such  as  weak  security,  and  is  unable  to  handle  large  volumes  of  management  data 
efficiently.  SNMPv2  incorporated  more  administrative  structure  and  better  security  fea¬ 
tures.  These  cause  complexity  in  implementation  and  incompatibility  with  SNMP  version 
1,  thus  making  it  unsuccessful  in  the  market.  [16] 

In  contrast  to  the  management  protocols  discussed  above,  CORBA  is  not  specifi¬ 
cally  developed  for  network  management  purposes.  Primarily  “a  programming  technol¬ 
ogy  for  distributed  computing,  CORBA  enables  components  of  various  application  pro¬ 
grams  to  communicate  with  one  another”  [17]  transparently.  This  prompted  the  Teleman¬ 
agement  Forum  (TMF)  to  adopt  it  “as  the  preferred  distribution  technology”  for  network 
management  and  created  standards  that  define  CORBA  objects  and  methods  to  be  used  at 
the  network  management  layer-element  management  layer  (NML-EML)  interface.  [17] 

Figure  1  shows  a  typical  network  management  architecture  with  CORBA  imple¬ 
mentations.  The  NML-EML  interface  in  this  case  is  referred  to  as  a  northbound  CORBA 
interface.  It  is  so  named  as  the  interface  provides  services  upwards  from  the  perspective 
of  the  EMS.  Similarly,  the  southbound  CORBA  interface  shown  in  Eigure  1  provides 
services  downwards  with  respect  to  the  EMS.  The  Cisco  products  in  this  study  use  GIOP, 
which  is  a  specific  CORBA  implementation. 


NMS 


Northbound 
CORBA 
_  ^  Interface 

V" 

EMS 


Southbound 

CORBA 


Interface 


Eigure  1 .  Typical  network  management  architecture  with  CORBA  implementations 
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D,  CTC 

“Cisco  Systems  (Cisco)  more  or  less  invented  the  router”  [6]  by  integrating  their 
routing  technology  and  SONET  technology  on  a  single  platform.  Cisco  is  able  to  provide 
“multiservice  optical  networking”  to  the  business  community  [18].  For  this  study,  the 
Cisco  Optical  Network  System  15454  (ONS  15454),  with  a  capability  for  supporting 
time-division  multiplexing  and  high-speed  optical  and  gigabit  networking,  was  used. 

The  central  processing  unit  (CPU)  of  Cisco  ONS  15454  is  the  Cisco  Timing  Control  Card 
Plus  (TCC+).  It  performs  NE  management  through  an  EMS  CTC,  which  is  stored  in  its 
non-volatile  memory  [19]. 

CTC  is  the  EMS  shipped  with  Cisco  ONS  15454.  It  can  manage  up  to  50  NEs 
concurrently.  CTC  is  installed  automatically  onto  the  workstation  that  is  connected  to 
Cisco  ONS  15454.  It  provides  a  graphical  user  interface  (GUI)  that  contains  “three  pri¬ 
mary  views,”  namely,  the  network,  node,  and  card  views.  The  network  view  presents  the 
entire  network  in  graphical  format  for  network  management.  It  allows  the  user  to  install  a 
location  map,  e.g.,  the  United  States  map.  The  network  topology  is  built  by  adding  icons, 
representing  nodes,  onto  the  location  map.  The  nodes’  statuses  are  represented  by  the 
colors  of  their  icons.  The  node  view  presents  a  node  by  displaying  Cisco  ONS  15454’s 
shelf  in  graphical  format  showing  all  the  cards  in  the  node.  The  user  is  able  to  manage  a 
node  through  this  view.  Similar  to  the  network  view,  each  card’s  color  represents  its 
status.  The  card  view  simply  shows  a  specific  card  based  on  the  user’s  selection.  The  user 
“performs  card  and  port-specific  maintenance  tasks  in  this  view.”  [19]  The  functions 
available  are  dependent  on  the  card  selected. 

CTC  connects  to  ONS  15454  using  the  SONET  data  communication  channel 
(DCC);  as  such,  it  is  able  to  search  and  discover  other  ONS  15454s  connected  to  the 
DCC.  Nevertheless,  CTC  is  able  to  connect  to  ONS  15454  using  an  Internet  Protocol 
(IP)  connection.  However,  in  this  case  it  would  be  unable  to  perform  the  search  and  dis¬ 
cover  feature.  CTC  is  also  able  to  support  a  northbound  CORBA  interface  for  communi¬ 
cation  to  a  NMS.  [19] 
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E,  CTM  4,6 

CTM  4.6  is  the  most  advanced  optical  EMS  for  Cisco  ONS  15000  series  products. 
It  uses  CTC  to  collect  network  information,  via  SNMPv2,  that  is  stored  in  an  external  da¬ 
tabase.  The  presence  of  the  external  database  enables  it  to  manage  up  to  2500  NEs. 

Apart  from  providing  all  the  capabilities  of  the  CTC,  such  as  GUI  and  manage¬ 
ment  functions,  CTM  4.6  is  also  able  to  collate  extensive  performance  monitoring  (PM) 
statistics  across  the  network  for  display  or  export.  Its  ability  to  cope  with  heavy  load  sce¬ 
narios  allows  Cisco  to  offer  it  as  a  high  availability  solution  to  customers.  Eike  the  CTC, 
CTM  4.6  also  has  an  optional  Gateway/CORBA  component  to  support  a  northbound 
CORBA  interface  to  integrate  with  a  NMS  [20]. 


F,  SUMMARY 

SONET  network  management  tools  and  products  were  introduced  in  this  chapter 
with  brief  discussion  of  common  network  management  protocols.  An  overview  of  CTC 
and  CTM  4.6  was  also  provided  to  give  an  insight  to  the  products. 

The  next  chapter  describes  the  laboratory  SONET  network  setup  and  the  proce¬ 
dures  performed  to  capture  the  network  load  for  this  study. 
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III.  LABORATORY  SETUP  AND  PROCEDURES 


A,  CHAPTER  OVERVIEW 

This  chapter  describes  the  SONET  network  and  equipment  configuration  in  the 
laboratory.  Next,  the  chapter  will  briefiy  recount  the  steps  and  challenges  for  setting  up 
the  equipment.  Last  but  not  least,  the  chapter  will  also  discuss  the  procedures  performed 
to  collect  data  for  analysis. 


B.  LABORATORY  SETUP 

Figure  2  shows  a  logical  implementation  of  a  SONET  network  in  the  Advanced 
Networking  Laboratory. 


Packet  Analyzer 
(Ethereal) 


Packet  Analyzer 
(Ethereal) 


IP  Netwoi 


192.168.200.112 
(CTM  4.6  Client) 


Figure  2.  Logical  implementation  of  the  Advanced  Networking  Laboratory’s 

SONET  network 
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As  can  be  seen  from  Figure  1,  four  ONS  15454s  are  connected  in  a  ring  to  form  a 
SONET  network.  One  of  the  ONS  15454  is  connected  to  an  IP  Network  and  forms  the 
bridge  between  the  SONET  and  the  IP  networks. 

C.  EQUIPMENT  CONFIGURATION 
1,  Installing  ONS  15454s 

Eieutenant  Matthew  Klobukowski  of  the  Advanced  Networking  Eaboratory  set  up 
the  SONET  network  by  installing  the  four  ONS  15454s  and  conneeting  them  in  the  ring. 
In  addition,  he  had  assigned  IP  addresses  and  NE  Identifieations  (IDs)  to  them  as  shown 
in  Table  E 


NE  ID 

IP  Address 

Carmel 

192.168.200.210 

Paeific  Grove 

192.168.200.211 

Monterey 

192.168.200.212 

Salinas 

192.168.200.213 

Table  1.  Assigned  NEs’  IDs  and  IP  addresses 

This  SONET  network  is  configured  to  simulate  a  regional  network  across  tens  of 
miles.  The  NE  ID  represents  the  pseudo-loeation  of  the  NE. 

2.  Installing  CTC 

CTC  is  a  Java  application  that  is  downloaded  automatically  to  a  machine  each 
time  the  machine  connects  to  an  ONS  15454.  As  such,  CTC  can  only  be  launched 
through  a  web  browser  with  a  Java  Plug-in.  This  web  browser  is  required  only  during  the 
intial  launching.  CTC  version  4.1,  as  used  in  the  Advaneed  Networking  Eaboratory,  was 
found  to  be  compatible  only  with  Java  Runtime  Environment  (JRE)  version  1.3.102.  It 
was  found  that  the  web  browser  is  unable  to  launeh  CTC  if  Java  2  Runtime  Environment 
(J2RE)  version  1.4.2_04  was  used. 
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For  this  study,  CTC  was  launched  on  a  Dell  PowerEdge  2650  running  Microsoft 
Windows  2003  Server,  which  is  designated  as  a  CTC  client  in  Figure  1,  to  monitor  the 
SONET  network. 

3.  Installing  CTM  4.6 

The  CTM  4.6  server  software  only  runs  on  Sun  Solaris  8  Operating  System  (OS) 
and  requires  Oracle  8i,  an  external  database,  during  its  operations.  In  addition,  a  personal 
computer  (PC)  is  required  to  eonnect  to  the  CTM  4.6  server  as  a  CTM  4.6  elient  for  user- 
related  activities  [20]. 

As  a  machine  with  Sun  Solaris  8  OS  was  unavailable,  the  Sun  Blade  1000  in  the 
Advanced  Networking  Eaboratory,  previously  configured  with  Sun  Solaris  9  OS,  was 
reconfigured  with  Sun  Solaris  8  OS.  Subsequently,  Oracle  8i  Enterprise  Edition,  CTM 
4.6  server,  CTM  database  schema,  and  CTM  web  server  were  installed  onto  the  machine. 
Next  the  CTM  4.6  client  was  installed  onto  a  PC  running  Windows  XP. 

As  mentioned  in  Chapter  II,  CTM  4.6  uses  SNMPv2  as  the  underlying  manage¬ 
ment  protocol.  Therefore,  SNMPv2  has  to  be  enabled  on  the  ONS  15454s.  As  shown  in 
Figure  3,  CTC  was  used  to  enable  SNMPv2  on  the  NEs.  Figure  3  also  shows  that 
SNMPv2  was  eonfigured  to  use  the  community  name  “AdvNetEab”  and  UDP  port  162 
for  sending  SNMPv2  traps  to  the  CTM  4.6  server  (IP  address  -  192.168.200.10).  In  addi¬ 
tion,  the  “Maximum  Trap  per  Second”  was  set  to  0,  which  implies  all  traps  are  sent  to  the 
CTM  4.6  server. 

Next,  the  NEs  to  be  monitored  by  the  CTM  4.6  server  were  added  through  the 
CTM  4.6  client  and  the  performance  monitoring  option  in  the  CTM  4.6  was  enabled. 
Figure  4  shows  the  CTM  4.6  processes  running  on  the  server.  The  processes  “CTM 
Server”,  “SNMPTrapService”,  and  “SMService”  indicate  that  the  server  is  running  prop¬ 
erly.  The  NE-specific  process  is  shown  as  “NEServioe-21”  and  the  PM-specific  proeess 
is  shown  as  “PMService-2”.  The  “Apache  Web  Server”  indicates  that  the  web  server  op¬ 
tion  is  installed  and  running  and  that  the  CTM  4.6  elient  is  able  to  download  information 
from  the  CTM  4.6  server  through  Hypertext  Transfer  Protocol  (HTTP). 
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Figure  3.  ONS  15454s’  SNMPv2  configuration 


Figure  4.  CTM  4.6  processes  running  on  the  server 
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D,  DATA  COLLECTION 

Ethereal,  an  open-source  packet  analyzer  freeware  program,  was  used  to  capture 
the  traffic  for  analysis.  As  can  be  seen  from  Figure  1,  Ethereal  was  deployed  to  passively 
monitor  the  network  interfaces  of  the  CTC  client  and  the  CTM  4.6  Server. 

1.  Collecting  the  CTC ’s  Traffic 

As  mentioned  in  Chapter  II,  the  CTC  connects  to  an  NE,  from  which  it  can  dis¬ 
cover  and  manage  other  NEs  through  the  DCC.  Therefore,  by  capturing  the  data  commu¬ 
nications  between  the  CTC  and  the  connected  NE,  it  is  possible  to  determine  the  over¬ 
head  traffic  injected  by  the  CTC  and  the  managed  NEs  onto  the  DCC.  Ethereal  was 
placed  on  the  network  to  capture  the  IP  traffic  inbound  and  outbound  to  the  CTC  client. 
This  IP  traffic  is  essentially  the  traffic  on  the  DCC  that  is  forwarded  to  the  CTC  client  by 
its  connected  NE  using  the  IP  network.  In  this  study,  the  CTC  was  left  running  for  a  pe¬ 
riod  of  10  days  to  generate  sufficient  network  traffic  for  analysis. 

2,  Collecting  the  CTM  4,6’s  Traffic 

Similar  to  the  way  the  CTC’s  traffic  was  collected.  Ethereal  was  deployed  to 
monitor  the  inbound  and  outbound  communications  from  the  CTM  4.6  server.  SNMPv2 
agents  were  configured  to  run  on  the  ONS  15454s  and  report  to  the  CTM  4.6  server.  In 
this  case,  all  the  SNMPv2  traps  were  sent  to  the  CTM  4.6  server  through  the  IP  network. 
Thus  the  traffic  captured  on  the  IP  network  is  representative  of  the  load  generated  by 
CTM  4.6  and  the  managed  NEs. 

E,  SUMMARY 

The  Advanced  Networking  Eaboratory’s  SONET  network  and  the  equipment 
were  initially  discussed  in  this  chapter.  Next  the  challenges  encountered  during  the  instal¬ 
lation  of  the  equipment  were  briefly  described.  The  chapter  concluded  with  a  discussion 
of  the  data  collection  process. 

The  next  chapter  provides  some  background  knowledge  of  probability  theory  used 
in  the  analysis  of  the  data.  The  concept  of  self-similarity  will  also  be  briefly  discussed. 
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IV.  PROBABILITY  THEORY  AND  SELF-SIMILARITY 


A.  CHAPTER  OVERVIEW 

This  chapter  aims  to  provide  a  brief  review  of  probability  theory  and  the  eoneept 
of  self-similarity.  The  first  part  of  the  ehapter  briefly  reviews  the  diserete  random  vari¬ 
able  and  its  probability  distributions.  The  seeond  part  of  the  chapter  briefly  states  the 
queuing  equations  used  in  this  study.  The  last  part  of  this  ehapter  provides  an  overview 
on  the  eoneept  of  self-similarity  and  diseusses  a  teehnique  used  to  estimate  the  Hurst 
value,  a  key  parameter  for  determining  the  degree  of  self-similarity. 


B,  DISCRETE  RANDOM  VARIABLE 

A  discrete  random  variable,  X,  is  defined  by  its  probability  distribution: 


P^(t)  =  Pr[Z=<:] 

(4.1) 

all  k 

(4.2) 

In  addition,  the  discrete  random  variable,  X,  has  the  following  eharacteristies: 

Mean: 

E'[X]  =  '^kVx\^x  =  k\ 

aWk 

(4.3) 

Second  Moment: 

£[x']  =  ^k"  Pr[x  =  k] 

all/t 

(4.4) 

Variance: 

Var[Z]  =  o-;=£[z^]-{£[jr]}" 

(4.5) 

Standard  Deviation: 

^v  =  VVar[X] 

(4.6) 

Coeffieient  of  Variation: 

(4.7) 
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As  stated  in  [21],  “the  mean  is  known  as  a  first-order  statistic”  while  “the  second 
moment  and  the  variance  are  second-order  statistics”.  Two  essential  probability  distribu¬ 
tions  used  in  queuing  theory  are  discussed  next. 

1.  Exponential  Distribution 

The  exponential  distribution  used  in  queuing  analysis  has  a  probability  distribu¬ 
tion  function,  F{x),  and  a  probability  density  function,  / (x),  given  by: 


F{x)  =  1-e 


-Xx 


f{x)  =  Xe-^\ 

The  mean  of  the  exponential  distribution  is  equal  to  its  standard  deviation: 

1 


Fx 


X 


(4.8) 


(4.9) 


(4.10) 


In  queuing  theory,  the  service  time,  that  is  the  packet  transmission  time  of  a 
packet  switched  network,  is  often  assumed  to  be  exponential  [21]. 


2.  Poisson  Distribution 

The  Poisson  distribution  is  another  distribution  that  is  used  in  queuing  analysis.  It 
takes  on  the  form: 


Pr[X  =  k]  =  ^e  ^ 


(4.11) 


The  mean  of  the  Poisson  distribution  is  equal  to  its  variance: 

^x=cjI=X.  (4.12) 

Figure  5  shows  an  example  of  the  Poisson  distribution  with  /I  =  4 .  As  shown  in 
the  figure,  there  are  two  maxima  at  k  =  3  and  k  =  4 ,  which  correspond  to  k  =  X-l  and 
k  =  X,  respectively. 
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Figure  5.  Poisson  distribution  with  A  =  4  (After  Ref.  [21].) 


In  queuing  analysis,  the  items  arriving  at  the  queue  are  usually  modeled  after  the 
Poisson  distribution  pattern;  thus  from  Equations  (4.1 1)  and  (4.12): 


( AT^ 

Pr  \k  items  arrive  in  the  time  interval  T  ]  =  ^ 


k\ 


E  [number  of  items  to  arrive  in  time  interval  T ]  =  AT 


(4.13) 

(4.14) 

(4.15) 


Mean  arrival  rate,  in  items  per  second  =  A. 

If  the  interarrival  times,  the  times  between  arrivals  of  items,  are  assumed  to  fol¬ 
low  the  exponential  distribution,  then  from  Equations  (4.8)  and  (4.10): 


Pr  [interarrival  time  <t\  =  \-e 


E  [interarrival  time]  =  — . 


-At 


(4.16) 


(4.17) 


Therefore,  it  can  be  seen  from  Equation  (4.17)  that  the  mean  interarrival  time  is 
inversely  proportional  to  the  arrival  rate  [21]. 
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C.  QUEUING  EQUATIONS 

In  this  study,  queuing  theory  is  applied  to  ealeulate  the  utilization,  p,  of  the 
SONET  link.  As  sueh,  the  queuing  equations  in  [21]  that  are  used  in  the  next  ehapter  are 
briefly  diseussed  below. 

From  Equation  (4.17): 

T  = i - .  (4.18) 

Mean  interarrival  time 


As  mentioned  above,  the  serviee  time,  1$,  is  the  paeket  transmission  time  of  a 
paeket  switehed  network.  Therefore,  1$  is  related  to  the  paeket  size  and  the  link  speed  as: 


T  = 


Mean  packet  size  (in  bytes)  x  8 


Eink  speed 

Knowing  the  arrival  rate  and  the  service  time,  p  can  be  calculated  through: 

p  =  ATs. 


(4.19) 


(4.20) 


D,  SELF-SIMILARITY 

The  exponential  and  Poisson  distributions  provide  a  good  estimate  for  the  net¬ 
work  traffic  into  a  single-server  queue.  However,  these  models  are  unable  to  take  into 
account  the  burstiness  of  the  network  traffic  accurately.  This  has  led  to  the  idea  of  model¬ 
ing  network  traffic  using  the  concept  of  self-similarity.  Based  on  fractals  and  chaos  the¬ 
ory,  the  concept  of  self-similarity  is  becoming  important  in  the  description  of  network 
traffic  [21].  In  this  subsection,  the  concept  is  briefly  introduced  to  provide  adequate  in¬ 
formation  for  analyzing  the  captured  traffic. 

1,  Estimation  of  Self-similarity 

A  significant  measure  of  self-similarity  is  the  Hurst  {H)  parameter.  A  process  is 
statistically  self-similar  if  0.5  <  if  <  1 .  There  are  a  number  of  ways  to  estimate  H.  In  this 

study,  H  is  estimated  by  analyzing  the  variances  of  aggregated  processes,  x^"'^ ,  where  m 
is  an  integer  representing  the  number  of  samples  considered  in  a  given  sample  window. 
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As  was  stated  in  [21],  for  self-similar  processes,  the  variances  satisfy  the  follow¬ 
ing  relationship  for  large  values  of  m: 


where  fi  is  defined  as; 


Var(x('"^)  □ 


Var(x) 


m 


(4.21) 


H  =  \ 


1 

2  ■ 


(4.22) 


Taking  the  log  on  both  sides  of  Equation  (4.21); 


log  Varl^x^""^^  □  log[Var(x)]-y01og(m). 


(4.23) 


A  variance-index  plot  is  obtained  by  plotting  log(m)  versus  log 


Var^x 


{my 


of 


Equation  (4.23).  The  gradient  of  the  variance-index  plot  is  the  approximate  value  of  fi . 
Next,  Equation  (4.22)  is  used  to  calculate  H,  which  provides  an  indication  of  the  degree 
of  self-similarity  [21,22]. 


2.  Queue  Depth  for  Self-similar  Traffic 

The  queue  depth  of  a  network,  q,  is  related  to  the  mean  network  link  utilization, 
p,  and  H\ 


P 


1 


H 

{\-p)(Ph) 


(4.24) 


Eor  a  system  with  exponential  interarrival  and  service  times  (also  termed  as  M/M/1), 
//  =  0.5  [21]. 
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E,  SUMMARY 

This  chapter  began  by  reviewing  the  eharaeteristies  of  the  diserete  random  vari¬ 
able  and  some  related  probability  distributions.  The  exponential  and  Poisson  distributions 
were  briefly  mentioned.  Next  the  ehapter  briefly  stated  the  queuing  equations.  Then  the 
eoneept  of  self-similarity  and  the  Hurst  parameter,  H,  whieh  is  used  to  determine  the  de¬ 
gree  of  self-similarity,  were  introdueed.  Finally,  the  ehapter  deseribed  a  teehnique  to  es¬ 
timate  H  and  provided  the  relationships  between  the  queue  depth,  mean  utilization,  and 
the  Hurst  pararmeter,  H. 

The  next  ehapter  begins  by  deseribing  the  traffie  analysis  performed  using  a 
paeket  analyzer.  The  remainder  of  the  ehapter  presents  the  statistieal  traffie  analysis. 
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V.  TRAFFIC  ANALYSIS  AND  FINDINGS 


A,  CHAPTER  OVERVIEW 

This  chapter  starts  by  discussing  the  observations  of  the  initial  traffie  analysis  per¬ 
formed  using  a  packet  analyzer.  Next,  the  chapter  briefly  deseribes  the  data  pruning  proe- 
ess  and  further  discusses  the  findings  of  the  traffie  analysis  performed  using  the  statistieal 
tools  presented  in  Chapter  IV.  Last,  the  results  from  the  traffie  analysis  are  presented. 


B.  TRAFFIC  ANALYSIS  USING  ETHEREAL 

As  mentioned  in  Chapter  III,  the  CTC  and  the  CTM  4.6’s  traffic  are  eaptured  us¬ 
ing  Ethereal.  In  addition  to  monitoring  the  traffie.  Ethereal  is  also  able  to  deeipher  the 
traffic  into  commonly  used  (open  standards)  protoeols.  Eigure  6  shows  a  sereen  shot  of 
Ethereal  deciphering  the  CTC’s  traffic. 


Eigure  6.  Sereen  shot  of  Ethereal  deciphering  the  CTC’s  traffie 
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1,  Observations  Made  on  the  CTC’s  Traffic 

The  CTC’s  traffic  was  captured  between  June  11,  2004  and  June  20,  2004,  over  a 
period  of  235.5  hours.  Using  Ethereal,  it  was  observed  that  the  CTC  communicated  with 
the  managed  NEs  using  Cisco’s  proprietary  Socks  protocol  that  connects  to  Transport 
Control  Protocol  (TCP)  Port  1080  on  the  NEs.  Although  Ethereal  cannot  decipher  the 
Socks  protocol,  it  can  be  observed  from  the  payload  (data)  section  that  this  Socks  proto¬ 
col  incorporated  GlOP  (a  type  of  CORBA  implementation).  In  addition,  further  analysis 
revealed  that  the  CTC’s  user-commands  (sent  through  the  CTC  client)  were  forwarded  to 
the  NEs  using  GlOP.  Table  2  shows  a  summary  of  the  type  of  traffic  and  the  number  of 
packets  observed  in  the  captured  traffic.  The  Socks  traffic  is  the  data  of  interest  (suppos¬ 
edly  the  actual  traffic  on  the  DCC),  while  the  TCP  overhead  includes  traffic  for  setting  up 
TCP  connections,  tearing  down  TCP  connections,  TCP  acknowledgment,  and  TCP  re¬ 
transmission.  The  other  communications  seen  on  the  network  are  networking  protocols 
like  Address  Resolution  Protocol  (ARP),  UDP,  and  HTTP,  etc.,  which  are  unrelated  to 
this  study. 


Type  of  Traffic 

Number  of  Packets 

Socks  communications  between  CTC  and  the  managed  NEs 

124,784 

TCP  overhead  for  CTC’s  Socks  communications 

148,796 

Other  communications  on  the  network 

31,941 

Total  packets  captured  on  the  network 

305,521 

Table  2.  Summary  of  the  CTC’s  traffic  captured  between  June  11,  2004  and 

June  20,  2004 

2.  Observations  Made  on  tbe  CTM  4,6’s  Traffic 

The  CTM  4.6’s  traffic  was  captured  between  July  20,  2004  and  July  30,  2004, 
over  a  period  of  257  hours.  A  summary  of  the  captured  traffic  is  as  shown  in  Table  3. 
Similar  to  the  CTC’s  traffic,  the  Socks  traffic  is  the  portion  of  the  CTM  4.6’s  traffic  that 
uses  Cisco’s  proprietary  Socks  protocol.  Similarly,  the  TCP  overhead  includes  traffic  for 
setting  up  TCP  connections,  tearing  down  TCP  connections,  TCP  acknowledgments,  and 
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TCP  retransmissions.  An  additional  protocol  observed  in  this  set  of  data  is  SNMPv2. 
Other  traffic  are  communications  that  are  unrelated  to  this  study.  These  include  other  pro¬ 
tocols  observed  on  the  network  and  the  CTM  4.6  client’s  traffic  (user  commands),  which 
are  made  up  of  GlOP  and  the  Oracle  database’s  TNS  connections. 


Type  of  Traffic 

Number  of  Packets 

Socks  communications  between  CTM  and  the  managed  NEs 

203,278 

TCP  overhead  for  CTM’s  Socks  communications 

260,461 

SNMPv2  traffic 

7,364 

Other  communications  on  the  network 

193,333 

Total  packets  captured  on  the  network 

664,436 

Table  3.  Summary  of  the  CTM  4.6’s  traffic  captured  between  July  20,  2004  and 

July  30,  2004 

Through  Ethereal,  it  is  observed  that  the  CTM  4.6  mainly  communicated  with  its 
managed  NEs  in  the  same  manner  as  the  CTC,  and  that  the  SNMPv2  traffic  only  forms 
1%  of  the  total  traffic.  This  was  unexpected  as  it  was  thought  that  the  CTM  4.6  collects 
the  NEs’  information  through  the  CTC  using  SNMPv2  as  the  underlying  network  man¬ 
agement  protocol.  However,  close  inspection  revealed  that  the  CTM  4.6  performs  a 
“GetBulk”  operation  to  the  NEs  every  24  hours.  This  “GetBulk”  operation  enables  the 
CTM  4.6  to  collect  large  amount  of  data  from  the  NEs  efficiently  through  a  single  opera¬ 
tion  [5].  In  addition  to  these  “GetBulk”  operations,  SNMPv2  “trap”  operations  sent  by 
the  NEs  were  also  observed. 

C.  DATA  PRUNING 

After  identifying  the  types  of  network  traffic  that  were  captured,  the  next  step  was 
to  extract  those  relevant  to  this  study  for  further  analysis.  Eirst,  a  summary  of  the  cap¬ 
tured  data  was  printed  out  in  text  format  (i.e.,  divided  into  columns)  from  Ethereal  and 
saved  into  a  flat  file.  A  screen  shot  of  the  text  print  out  from  Ethereal  is  shown  in  Eigure 
7.  The  important  fields  are  the  “Time”  and  “Eength”  fields. 
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P  Ethereal_printout.txt 

-  Notepad 

Fie  Edit 

Format  \fiew  Help 

No. 

Time 

Source 

Destination 

Protocol 

Length  Info 

A 

1 

0.000000 

192.168.200.7 

192.168.200.210 

Socks 

631 

Unknown 

2 

0.053224 

192.168.200.210 

192.168.200.7 

TCP 

64 

1080  >  4680 

[ACK] 

Seq=0  Ack=577  Wi 

3 

0.063914 

192.168.200.210 

192.168.200.7 

Socks 

79 

Unknown 

4 

0.281020 

192.168.200.7 

192.168.200.210 

TCP 

54 

4680  >  1080 

[ACK] 

Seq=577  Ack=25  ^ 

5 

62.505220 

192.168.200.7 

192.168.200.210 

Socks 

631 

Unknown 

6 

62.508353 

192.168.200.210 

192.168.200.7 

TCP 

64 

1080  >  4677 

[ACK] 

Seq=0  Ack=577  Wi 

7 

62. 517095 

192.168.200.210 

192.168.200.7 

Socks 

79 

Unknown 

8 

62.629954 

192.168.200.7 

192.168.200.210 

TCP 

54 

4677  >  1080 

[ACK] 

Seq=577  Ack=25  Vt 

9 

96.047741 

DellComp  fd:6d:8c 

Broadcast 

ARP 

60 

Who  has  192 

168.200.1?  Ten  192.1  1 

10 

105.603163 

192.168.200.7 

192.168.200.210 

Socks 

631 

Unknown 

11 

105.692361 

192.168.200.210 

192.168.200.7 

TCP 

64 

1080  >  4687 

[ACK] 

Seq=0  Ack=577  Wi 

12 

105.703077 

192.168.200.210 

192.168.200.7 

Socks 

79 

Unknown 

13 

105.837301 

192.168.200.7 

192.168.200.210 

TCP 

54 

4687  >  1080 

[ACK] 

Seq=577  Ack=25  Ift 

14 

110.760067 

192.168.200.7 

192.168.200.210 

Socks 

631 

Unknown 

15 

110.808671 

192.168.200.210 

192.168.200.7 

TCP 

64 

1080  >  1249 

[ACK] 

Seq=0  Ack=577  Wi 

16 

110.818068 

192.168.200.210 

192.168.200.7 

Socks 

79 

Unknown 

17 

110.978496 

192.168.200.7 

192.168.200.210 

TCP 

54 

1249  >  1080 

[ACK] 

Seq=577  Ack=25  1a 

18 

120.073842 

192.168.200.7 

192.168.200.210 

Socks 

631 

Unknown 

19 

120.119966 

192.168.200.210 

192.168.200.7 

TCP 

64 

1080  >  4680 

[ACK] 

Seq=25  Ack=1154 

20 

120.130467 

192.168.200.210 

192.168.200.7 

Socks 

79 

Unknown 

21 

120.276712 

192.168.200.7 

192.168.200.210 

TCP 

54 

4680  >  1080 

[ACK] 

Seq=1154  Ack=50 

22 

182.518734 

192.168.200.7 

192.168.200.210 

Socks 

631 

Unknown 

23 

182.522510 

192.168.200.210 

192.168.200.7 

TCP 

64 

1080  >  4677 

[ACK] 

Seq=25  Ack=1154 

24 

182.531272 

192.168.200.210 

192.168.200.7 

Socks 

79 

Unknown 

25 

182.737257 

192.168.200.7 

192.168.200.210 

TCP 

54 

4677  >  1080 

[ACK] 

Seq=1154  Ack=50 

26 

225.712849 

192.168.200.7 

192.168.200.210 

Socks 

631 

Unknown 

27 

225.806542 

192.168.200.210 

192.168.200.7 

TCP 

64 

1080  >  4687 

[ACK] 

Seq=25  Ack=1154 

28 

225.817755 

192.168.200.210 

192.168.200.7 

Socks 

79 

Unknown 

29 

225.947009 

192.168.200.7 

192.168.200.210 

TCP 

54 

4687  >  1080 

[ACK] 

Seq=1154  Ack=50 

30 

230.822927 

192.168.200.7 

192.168.200.210 

Socks 

631 

Unknown 

31 

230.869420 

192.168.200.210 

192.168.200.7 

TCP 

64 

1080  >  1249 

[ACK] 

Seq=25  Ack=1154 

32 

230.878795 

192.168.200.210 

192.168.200.7 

Socks 

79 

Unknown 

33 

231.088340 

192.168.200.7 

192.168.200.210 

TCP 

54 

1249  >  1080 

[ACK] 

Seq=1154  Ack=50 

34 

232.441897 

192.168.200.5 

192.168.200.255 

BROWSER 

252 

Domain/Workgroup  . 

Announcement  ADVN  ^ 

< 

> 

Figure  7.  Screen  shot  of  a  text  print  out  from  Ethereal 

Next,  the  flat  file  was  imported  into  a  Microsoft  Access  database  table.  As  the 
import  was  done  using  fixed  column’s  width,  some  of  the  fields  were  imported  with  an 
additional  white  space  before  the  fields.  A  general  “Replace”  operation  was  performed  in 
Microsoft  Access  to  eliminate  the  additional  white  space. 

Microsoft  Access  allows  queries  on  the  data  based  on  a  field.  Thus  a  query  was 
performed  to  select  all  the  packets  using  the  Socks  protocol  and  the  query  result  was  cut 
and  pasted  into  an  empty  database  table.  Additional  queries  were  then  performed  on  the 
new  database  table  to  select  the  unwanted  data  (like  “TCP  Retransmission”  packets  of  the 
Socks  protocol)  for  deletion.  Finally,  the  pruned  data  was  exported  into  text  format,  from 
Microsoft  Access  using  “tab”  as  the  delimiter  and  saved  into  another  fiat  file.  Similar  op¬ 
erations  were  performed  to  extract  other  data  of  interest.  Using  this  process,  data  for  the 
following  were  generated;  CTC’s  Socks  traffic,  CTM  4.6’s  Socks  traffic,  CTM  4.6’s 
SNMP  traffic,  CTM  4.6’s  combined  Socks  and  SNMP  traffic,  and  CTM  4.6’s  Ethernet 
traffic  (which  includes  all  the  TCP/IP  traffic  related  to  the  Socks  and  the  SNMP  commu¬ 
nications). 
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D.  STATISTICAL  ANALYSIS 

As  mentioned  in  Chapter  IV,  in  queuing  theory  the  interest  lies  in  the  interarrival 
times  between  packets  and  the  packet  sizes  of  the  traffic.  The  interarrival  times  between 
packets  are  obtained  by  taking  the  differences  in  the  arrival  times  (corresponding  to  the 
“Time”  column  in  Figure  7)  between  two  adjacent  packets.  The  packet  sizes  are  simply 
the  packet  lengths  (corresponding  to  the  “Length”  column  in  Figure  7). 

Using  a  Mathcad  program  written  by  Lieutenant  James  Young  in  the  Summer 
2003  EC4850  class,  the  interarrival  times  and  packet  sizes  of  the  captured  traffic  were 
extracted  and  modeled  as  random  variables.  Next  a  set  of  data  samples  for  each  random 
variable  was  generated  and  exported  to  Microsoft  Excel  for  plotting. 

1,  Interarrival  Time  Distributions 

Using  the  generated  data  samples  for  interarrival  times,  the  interarrival  time  dis¬ 
tributions  are  plotted  in  Eigures  8  to  12  using  Microsoft  Excel. 


Interarrival  Time  DistributioD  for  CTC's  Socks  Traffic 


Time  (seconds) 


Eigure  8.  Interarrival  time  distribution  for  CTC’s  Socks  traffic 
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iDterarrival  Time  Distribution  for  CTM  4.6*s  Socks  Traltic 


Time  (seconds) 


Figure  9.  Interarrival  time  distribution  for  CTM  4.6’s  Socks  traffic 


Interarrival  Time  Distribution  for  CTM  4.6's  SXMP  Traffic 


Time  (seconds) 


Figure  10.  Interarrival  time  distribution  for  CTM  4.6’s  SNMP  traffic 
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iDterarrival  Time  Distribution  for  CTM  4.6's  Combined  Socks  <&  SN^IP  Traffic 


Time  (seconds) 


Figure  1 1 .  Interarrival  time  distribution  for  CTM  4.6’s  eombined 

Socks  &  SNMP  traffic 


Interarrival  Time  Distribution  for  CTM  4.6's  Ethernet  Traffic 


Time  (seconds) 


Figure  12.  Interarrival  time  distribution  for  CTM  4.6’s  Ethernet  traffic 
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From  the  figures,  it  can  be  seen  that  some  of  the  distributions  resemble  that  of  the 
exponential  distribution  with  a  linear  rate  of  decay,  A  <1,  and  the  majority  of  the  packets 
arrive  within  a  relatively  short  interarrival  time.  Figures  8  and  10  also  exhibit  a  long- 
range  dependency  characteristic  (with  a  few  samples  that  are  relatively  much  larger  than 
the  rest)  that  suggests  the  CTC’s  Socks  traffic  and  the  CTM  4.6’s  SNMP  traffic  are  self¬ 
similar  and  bursty  [21],  Using  Equations  (4.3)  to  (4.7)  in  Mathcad,  the  mean,  variance, 
and  coefficient  of  variation  of  the  interarrival  time  distributions  are  computed  as  shown 
in  Table  4.  Note  in  all  cases  the  coefficient  of  variation  implies  a  strong  tail  {crj  ju^  □  l). 


Type  of  Traffic 

Mean  (s) 

Variance  (s^) 

Coefficient  of 
Variation 

CTC’s  Socks  Traffic 

6.793 

273.854 

2.436 

CTM  4.6’s  Socks  Traffic 

4.553 

772.087 

6.103 

CTM  4.6’s  SNMP  Traffic 

120.043 

627080.020 

6.597 

CTM  4.6’s  Combined 

Socks  &  SNMP  Traffic 

4.394 

745.556 

6.215 

CTM  4.6’s  Ethernet  Traffic 

1.965 

323.759 

9.159 

Table  4.  Tabulated  statistics  for  the  interarrival  time  distributions 

Substituting  the  mean  values  in  Table  4  into  Equation  (4.18),  the  values  for  X  are 
computed  as  shown  in  Table  5,  which  confirms  that /I  <  1 . 


Type  of  Traffic 

2(s-') 

CTC’s  Socks  Traffic 

0.147 

CTM  4.6’s  Socks  Traffic 

0.220 

CTM  4.6’s  SNMP  Traffic 

0.008 

CTM  4.6’s  Combined 

Socks  &  SNMP  Traffic 

0.228 

CTM  4.6’s  Ethernet  Traffic 

0.509 

Table  5.  Tabulated  values  of  arrival  rate,  X,  for  the  interarrival  time  distributions 
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2,  Packet  Size  Distributions 

Similar  to  the  plotting  of  interarrival  time  distributions,  the  samples  of  the  packet 
size  are  used  to  plot  the  packet  size  distributions  in  Figures  13  to  17  using  Microsoft  Ex¬ 
cel.  Figure  13  shows  that  the  packet  size  distribution  of  the  CTC’s  Socks  traffic  is  non- 
deterministic.  Further,  this  suggests  that  the  traffic  is  self-similar.  On  the  other  hand,  the 
linear  decay  of  Figures  14,  16  and  17  show  a  slight  resemblance  to  the  exponential  distri¬ 
bution.  Although  a  small  peak  is  observed  for  packets  of  550  bytes  in  size,  the  majority  of 
the  traffic  is  small  in  size  (<  100  bytes).  Figure  15  indicates  that  the  CTM’s  SNMP  traffic 
exhibits  a  long-range  dependency  that  suggests  the  traffic  is  self-similar  and  bursty. 


Packet  Size  Distribution  for  CTC’s  SocksTraffic 


Packet  Size  (bytes) 


Figure  13.  Packet  size  distribution  for  CTC’s  Socks  traffic 
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Packet  Size  Distribution  for  CTM  4.6's  Socks  Traffic 


Packet  Size  (bytes) 


Figure  14.  Packet  size  distribution  for  CTM  4.6’s  Socks  traffic 


Figure  15.  Packet  size  distribution  for  CTM  4.6’s  SNMP  traffic 
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Packet  Size  Distribution  for  CTM  4.6's  Combined  Socks  &  SN^IP  Traffic 


Figure  16.  Packet  size  distribution  for  CTM  4.6’s  combined  Socks  &  SNMP  traffic 


Packet  Size  Distribution  for  CTM  4.6's  Ethernet  Tralfic 

1000000  -t 


100000  - 


Packet  Size  (b>tes) 


Figure  17.  Packet  size  distribution  for  CTM  4.6’s  Ethernet  traffic 
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As  in  the  analysis  of  the  interarrival  time,  the  mean,  varianee,  and  eoeffieient  of 
variation  of  the  paeket  size  distributions  are  eomputed  using  Equations  (4.3)  to  (4.7)  in 
Mathead  and  tabulated  in  Table  6  below. 


Type  of  Traffic 

Mean 

(bytes) 

Variance 

(bytes^) 

Coefficient  of 
Variation 

CTC’s  Soeks  Traffie 

222.972 

59095.784 

1.090 

CTM  4.6’s  Soeks  Traffie 

145.053 

21536.979 

1.012 

CTM  4.6’s  SNMP  Traffie 

455.214 

2627.746 

0.113 

CTM  4.6’s  Combined 

Soeks  &  SNMP  Traffie 

155.898 

24121.782 

0.996 

CTM  4.6’s  Ethernet  Traffie 

102.678 

13118.495 

1.112 

Table  6.  Tabulated  statisties  for  the  paeket  size  distributions 

The  mean  values  in  Table  6  are  then  substituted  into  Equation  (4.19)  to  ealeulate 
the  values  for  Ts.  In  the  ealeulations  involving  traffie  that  traverses  on  the  Seetion  DCC 
(SDCC),  i.e.,  the  CTC’s  Soeks  traffie,  the  CTM  4.6’s  Soeks  traffie,  the  CTM  4.6’s  SNMP 
traffie,  and  the  CTM  4.6’s  eombined  Soeks  and  SNMP  traffie,  the  SDCC’s  link  speed  of 
192  kbps  is  used.  Eikewise  the  Ethernet’s  link  speed  of  100  Mbps  is  used  in  the  ealeula¬ 
tions  for  the  CTM  4.6’s  Ethernet  traffie.  The  results  are  tabulated  in  Table  7  below. 


Type  of  Traffic 

Type  of  Link/Speed 

Ts 

CTC’s  Soeks  Traffie 

SDCC/192  kbps 

9.291  ms 

CTM  4.6’s  Soeks  Traffie 

SDCC/192  kbps 

6.044  ms 

CTM  4.6’s  SNMP  Traffie 

SDCC/192  kbps 

18.967  ms 

CTM  4.6’s  Combined 

Soeks  &  SNMP  Traffie 

SDCC/192  kbps 

6.496  ms 

CTM  4.6’s  Ethernet  Traffie 

Ethemet/100  Mbps 

8.214  ps 

Table  7.  Tabulated  values  of  serviee  time,  Ts,  for  the  paeket  size  distributions 
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3,  Link  Utilization 

With  the  results  in  Tables  5  and  7,  the  link  utilization  ean  be  eomputed  using 
Equation  (4.20).  The  link  utilizations  for  four  NEs  are  shown  in  Table  8.  Next,  the  re¬ 
sults  in  Table  8  are  linearly  extrapolated  to  obtain  the  link  utilizations  for  50  NEs  (the 
maximum  eapaeity  of  the  CTC)  and  2500NEs  (the  maximum  eapaeity  of  the  CTM  4.6), 
whieh  are  tabulated  in  Table  9. 


Type  of  Traffic 

Type  of  Link/Speed 

Link  Utilization 

CTC’s  Soeks  Traffie 

SDCC/192kbps 

1.37x10  ' 

CTM  4.6’s  Soeks  Traffie 

SDCC/192kbps 

1.33x10  ' 

CTM  4.6’s  SNMP  Traffie 

SDCC/192kbps 

1.58x10^" 

CTM  4.6’s  Combined 

Soeks  &  SNMP  Traffie 

SDCC/192kbps 

1.48x10^^ 

CTM  4.6’s  Ethernet  Traffie 

Ethernet/ 100  Mbps 

4.18x10^" 

Table  8.  Tabulated  link  utilizations  for  four  NEs 


Type  of  Traffic 

Type  of 
Link/Speed 

Link  Utilization 
for  50  NEs 

Link  Utilization 
for  2500  NEs 

CTC’s  Socks  Traffic 

SDCC/192kbps 

0.0171 

0.855 

CTM  4.6’s  Socks  Traffic 

SDCC/192kbps 

0.0166 

0.830 

CTM  4.6’s  SNMP  Traffic 

SDCC/192kbps 

1.98x10  ' 

0.099 

CTM  4.6’s  Combined 

Socks  &  SNMP  Traffic 

SDCC/192  kbps 

0.0185 

0.926 

CTM  4.6’s  Ethernet  Traffic 

Ethernet/ 100  Mbps 

5.23x10^' 

2.62x10^^ 

Table  9.  Einearly  extrapolated  link  utilizations  for  50  and  2500  NEs 

Erom  Table  9,  it  ean  be  seen  that  the  SDCC  ean  potentially  support  the  CTC’s 
Soeks  traffie  for  50  NEs  with  ease  and  for  up  to  2500  NEs  with  about  14%  of  spare  ea¬ 
paeity.  However,  the  CTM  4.6,  whieh  has  both  Soeks  and  SNMP  traffie  on  the  SDCC, 
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will  utilize  about  93%  of  the  SDCC’s  capacity  if  it  is  managing  2500  NEs.  The  results 
also  show  that  the  link  utilization  of  the  CTM  4.6’s  Ethernet  traffic  is  too  low  to  create 
any  impact.  Nevertheless,  this  is  based  only  on  the  analysis  of  first-order  statistics  and 
has  not  taken  into  account  the  burstiness  of  the  traffic.  This  will  be  examined  in  the  next 
subsection. 

4,  Estimation  for  Self-similarity 

Using  Mathcad,  the  data  points  for  the  variance-index  plots  were  generated  for 
values  of  m  =  1,  10,  32,  100,  320,  and  1000  that  correspond  to  values  of  log(m)  =  0,  1, 

1.5,  2,  2.5  and  3.  The  variance-interarrival  time  plots  for  the  different  types  of  traffic  are 
illustrated  in  Figures  18  to  22  while  the  variance-packet  size  plots  for  the  different  types 
of  traffic  are  shown  in  Figures  23  to  27.  In  all  the  plots,  the  data  points  are  joined  using 
linear  best-fit.  The  linear  function  of  the  straight  line  thus  corresponds  to  Equation  (4.23) 
and  its  gradient  is  p.  With  the  values  of  fi,  the  corresponding  values  of  H  are  computed  in 
Table  10  using  Equation  (4.22). 


Figure  18.  Variance-interarrival  time  plot  for  CTC’s  Socks  traffic 
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Figure  19.  Variance-interarrival  time  plot  for  CTM  4.6’s  Socks  traffic 


Figure  20.  Variance-interarrival  time  plot  for  CTM  4.6’s  SNMP  traffic 
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Figure  2 1 .  Variance-interarrival  time  plot  for  CTM  4.6 ’s  combined 

Socks  &  SNMP  traffic 


Figure  22.  Variance-interarrival  time  plot  for  CTM  4.6’s  Ethernet  traffic 
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Figure  23.  Variance-packet  size  plot  for  CTC’s  Socks  traffic 


Figure  24.  Variance-packet  size  plot  for  CTM  4.6’s  Socks  traffic 
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Figure  25.  Variance-packet  size  plot  for  CTM  4.6’s  SNMP  traffic 


Figure  26.  Variance-packet  size  plot  for  CTM  4.6’s  combined  Socks  &  SNMP  traffic 
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Figure  27.  Variance-packet  size  plot  for  CTM  4.6’s  Ethernet  traffic 


Type  of  Traffic 

P 

H 

CTC’s  Socks  Traffic  (Interarrival  Time) 

0.1731 

0.9135 

CTC’s  Socks  Traffic  (Packet  Size) 

0.143 

0.9285 

CTM  4.6’s  Socks  Traffic  (Interarrival  Time) 

0.99 

0.505 

CTM  4.6’s  Socks  Traffic  (Packet  Size) 

0.8867 

0.5567 

CTM  4.6’s  SNMP  Traffic  (Interarrival  Time) 

0.5952 

0.7024 

CTM  4.6’s  SNMP  Traffic  (Packet  Size) 

0.1869 

0.9066 

CTM  4.6’s  Combined  Socks  &  SNMP  Traffic 
(Interarrival  Time) 

0.9785 

0.5108 

CTM  4.6’s  Combined  Socks  &  SNMP  Traffic 
(Packet  Size) 

0.7547 

0.6227 

CTM  4.6’s  Ethernet  Traffic  (Interarrival  Time) 

0.6324 

0.6838 

CTM  4.6’s  Ethernet  Traffic  (Packet  Size) 

0.395 

0.8025 

Table  10.  Tabulated  values  for  p  and  H 
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From  the  values  of  H  obtained  in  Table  10,  it  ean  be  seen  that  with  the  exeeption 
of  the  CTM  4.6’s  Soeks  and  the  CTM  4.6’s  combined  Socks  and  SNMP  traffic  that  have 
values  of  //near  to  0.5,  thus  less  self-similar,  the  rest  have  a  high  degree  of  self¬ 
similarity.  The  high  values  of  H  also  suggest  that  the  CTC’s  Socks  traffic,  the  CTM  4.6’s 
SNMP  traffic  and  the  CTM  4.6’s  Ethernet  traffic  are  bursty.  This  matches  the  results  ob¬ 
tained  earlier  in  the  distributions  plots.  In  the  next  subsection,  the  impact  of  traffic  bursti- 
ness  on  the  network  utilization  is  examined. 

5,  Effects  of  Self-similarity  on  Queue  Depth 

Figures  28  to  30  show  plots  of  the  mean  utilization  of  the  network,  p,  versus  the 
queue  depth,  q,  in  Equation  (4.24)  for  the  values  of  //in  Table  10,  using  different  scales 
for  q. 


Queue  Depth  Requiremeuts  for  Self-similar  Tralee 


Figure  28.  Plot  of  utilization,  p,  versus  queue  depth,  q,  (scale  to  ^  =  10) 
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Queue  Depth  Requirements  for  Self-similar  Traffic 


0.5  0.6 

Utilization  (/?) 


Figure  29.  Plot  of  utilization,  p,  versus  queue  depth,  q,  (scale  to  ^  =  100) 


Queue  Depth  Requirements  for  Self-similar  TraHic 


0.5  0.6 

Utilization  {p) 


Figure  30.  Plot  of  utilization,  p,  versus  queue  depth,  q,  (scale  to  g  =  1000) 
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From  Figure  28,  it  can  be  seen  that  for  p  <  0.38,  q<  \  for  all  traffic.  The  maxi¬ 
mum  number  of  NEs  required  to  obtain  a  utilization  of  0.38  for  the  various  kind  of  traffic 
are  computed  in  Table  11,  which  confirms  the  earlier  conclusion  (based  on  first-order 
statistics)  that  the  CTM  4.6’s  Ethernet  traffic  does  not  create  any  significant  impact  on 
the  Ethernet  network. 


Type  of  Traffic 

Number  of  NEs 

CTC’s  Socks  Traffic 

1109 

CTM  4.6’s  Socks  Traffic 

1142 

CTM  4.6’s  SNMP  Traffic 

9620 

CTM  4.6’s  Combined 

Socks  &  SNMP  Traffic 

1027 

CTM  4.6’s  Ethernet  Traffic 

360,000 

Table  1 1 .  Maximum  number  of  NEs  required  to  obtain  a  utilization  of  0.38 

It  is  observed  from  Eigure  28  that  when  operating  the  CTC  at  p  >  0.38,  the  re¬ 
quirement  for  q  increases  steeply.  Eigure  30  also  shows  that  if  q  is  increased  from  1  to 
1000  to  accommodate  the  burstiness  of  the  CTC’s  Socks  traffic  (for  packet  size),  p  only 
increases  by  10%  to  0.49,  which  translates  to  the  ability  to  manage  1430  NEs.  Neverthe¬ 
less,  the  CTC’s  specification  is  only  to  manage  up  to  50  NEs  with  a  utilization  of  0.0171, 
which  is  significantly  below  0.38.  Therefore,  although  the  traffic  is  self-similar  and 
bursty,  the  low  utilization  ensures  a  low  requirement  for  q. 

As  mentioned  earlier,  the  operation  of  the  CTM  4.6  requires  both  the  CTM  4.6’s 
Socks  and  SNMP  traffic,  and  Table  9  shows  that  when  managing  2500  NEs,  the  utiliza¬ 
tion  for  the  CTM  4.6’s  combined  Socks  and  SNMP  traffic  will  reach  0.926.  On  the  other 
hand,  Eigure  29  shows  that  when  operating  at  p  =  0.926,  it  would  require  ^  =  100  (ap¬ 
proximately  15  kB  based  on  the  mean  packet  size  of  combined  Socks  and  SNMP  traffic) 
in  order  to  accommodate  the  CTM  4.6’s  combined  Socks  and  SNMP  traffic  (interarrival 
time).  Nevertheless,  if  the  CTM  4.6  is  operating  with  p  =  0.67  (which  translates  to  man- 
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aging  1800  NEs)  the  requirement  for  q  is  redueed  by  a  faetor  of  10.  Table  1 1  also  shows 
that  the  requirement  for  q  is  further  redueed  to  1,  if  it  is  managing  only  1027  NEs. 

Therefore,  depending  on  the  queuing  buffer  available,  it  is  possible  but  not  advis¬ 
able  to  use  the  CTM  4.6  for  managing  2500  NEs  as  elaimed  in  its  speeifieations.  For  safe 
operation,  it  is  reeommended  that  the  CTM  4.6  be  used  to  manage  not  more  than  1027 
NEs. 

E,  SUMMARY 

In  this  ehapter,  the  eaptured  traffie  was  first  analyzed  using  Ethereal  to  determine 
the  protoeols  used  by  the  CTC  and  the  CTM  4.6.  Next  the  ehapter  briefly  deseribed  the 
data  pruning  proeess.  Then  the  traffie  was  further  analyzed  using  statistieal  tools  men¬ 
tioned  in  Chapter  IV.  Finally,  the  results  of  the  analysis  were  diseussed  and  the  effeets  of 
the  self-similar  nature  of  the  traffie  were  briefly  illustrated. 

The  next  ehapter  summarizes  the  entire  study  and  diseusses  some  avenues  for  fur¬ 
ther  researeh  into  the  management  tools ’s  oharaeteristies. 


45 


THIS  PAGE  IS  INTENTIONALLY  LEET  BLANK 


46 


VI.  CONCLUSION  AND  FUTHER  RESEARCH  AREAS 


A.  CHAPTER  OVERVIEW 

The  first  part  of  this  chapter  summarizes  the  work  done  and  concludes  this  study. 
The  second  part  of  this  chapter  discusses  some  areas  which  were  identified  during  the 
course  of  this  work  for  further  study. 


B,  CONCLUSION 

This  study  began  with  preliminary  market  research  on  SONET  management  tools 
available  in  the  market  for  use  with  the  Cisco  ONS  15454.  It  had  been  found  that  most 
SONET/SDH  equipment  manufacturers  also  build  their  own  EMS  to  support  their  own 
products  and  that  few  third-party  EMSs  exist  that  can  interface  with  multi-vendor’s 
products.  Therefore,  for  the  purpose  of  this  study  two  Cisco’s  EMSs,  the  CTC  and  the 
CTM  4.6  are  deployed  onto  the  SONET  network  (consisting  of  four  ONS  15454s)  in  the 
Advanced  Networking  Eaboratory.  Subsequently,  packet  analyzers  are  deployed  to  pas¬ 
sively  capture  the  network  traffic  for  analysis. 

Using  Ethereal,  it  was  revealed  that  the  CTC  communicates  with  the  NEs  through 
a  connection  to  TCP  Port  1080.  This  connection  uses  a  proprietary  Socks  protocol  that 
incorporated  GIOP.  Similarly,  the  CTM  4.6  also  uses  the  same  Socks  protocol  (as  its 
main  communication  tool)  in  addition  to  using  SNMP.  The  captured  traffic  was  thus  di¬ 
vided  into  five  categories:  CTC’s  Socks  traffic,  CTM  4.6’s  Socks  traffic,  CTM  4.6’s 
SNMP  traffic,  CTM  4.6’s  Socks  and  SNMP  traffic,  and  CTM  4.6’s  Ethernet  traffic. 

Analyzing  the  interarrival  time  distributions  and  packet  size  distributions  of  the 
five  kinds  of  traffic  showed  that  the  interarrival  time  distributions  of  all  the  traffic  resem¬ 
ble  that  of  the  exponential  distribution  with  a  low  decay  rate  (<1).  While  only  the  packet 
size  distributions  of  the  CTM’s  4.6  Socks  traffic,  CTM  4.6’s  Socks  and  SNMP  traffic, 
and  the  CTM  4.6’s  Ethernet  traffic  resemble  the  exponential  distribution.  In  addition,  the 
interarrival  time  distributions  of  the  CTC’s  Socks  traffic  and  the  CTM  4.6’s  SNMP  traffic 
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and  the  packet  size  distributions  of  the  CTC’s  Socks  traffic  and  the  CTM  4.6’s  SNMP 
traffic  appear  to  exhibit  self-similarity  characteristics. 

Thus  higher-orders  statistics  are  used  to  estimate  the  Hurst  parameter  of  the  vari¬ 
ous  distributions.  It  was  found  that  the  CTC’s  Socks  traffic,  the  CTM  4.6’s  SNMP  traffic, 
and  the  CTM  4.6’s  Ethernet  traffic  are  self-similar  with  high  values  for  the  Hurst  pa¬ 
rameter.  On  the  other  hand,  the  CTM  4.6’s  Socks  traffic  and  the  CTM  4.6’s  combined 
Socks  and  SNMP  traffic  have  Hurst  parameter  values  closer  to  0.5,  which  is  the  Hurst 
parameter  value  for  M/M/1  traffic. 

From  the  first-order  statistics  of  the  interarrival  time  distributions  and  packet  size 
distributions,  the  link  utilizations  of  the  five  categories  of  traffic  were  computed  and  line¬ 
arly  extrapolated  to  obtain  the  link  utilizations  for  50  NEs  (the  CTC’s  capacity)  and  2500 
NEs  (the  CTM  4.6’s  capacity).  Eooking  at  the  low  link  utilization  of  0.171  for  the  CTC’s 
traffic  when  the  CTC  is  used  to  manage  50  NEs,  it  can  be  concluded  that  even  with  a 
high  Hurst  parameter  value,  the  CTC  still  would  not  have  any  problem  in  managing  50 
NEs  concurrently.  Similarly,  the  low  link  utilization  for  the  CTM  4.6’s  SNMP  traffic  and 
CTM  4.6’s  Ethernet  traffic  would  not  pose  any  problem  for  the  CTM  4.6,  even  with  high 
Hurst  parameter  values.  However,  the  CTM  4.6’s  combined  Socks  and  SNMP  traffic 
would  have  a  high  utilization  of  0.926  when  the  CTM  4.6  is  used  to  manage  2500  NEs. 

Through  the  plot  of  the  mean  network  utilization  versus  the  queue  depth  for  the 
estimated  Hurst  parameters,  it  can  be  seen  that,  in  order  to  accommodate  the  burstiness  of 
the  CTM  4.6’s  Socks  and  SNMP  traffic  (packet  size  distribution),  a  large  queuing  buffer 
is  required.  Thus  to  prevent  queuing  buffer  overflow,  it  is  recommended  that  the  CTM 
4.6  be  used  to  manage  up  to  a  maximum  of  1027  NEs,  operating  within  a  utilization  of 
0.38. 

In  conclusion,  this  study  provided  a  great  opportunity  for  the  author  to  investigate 
and  understand  Cisco  SONET  equipment  and  EMSs.  It  is  hoped  that  the  results  obtained 
herein  are  useful  to  telecommunications  network  service  providers  that  are  using  Cisco 
equipment. 
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C.  FURTHER  RESEARCH  AREAS 

In  the  course  of  working  on  this  thesis,  a  number  of  areas  were  not  investigated 
further  due  to  either  a  lack  of  required  resources  or  time.  In  this  subsection,  those  areas 
are  briefly  discussed. 

1,  Varying  the  Number  of  NEs 

In  this  study,  only  the  traffic  of  a  SONET  ring  with  four  NEs  was  captured.  The 
utilization  of  the  network  was  assumed  to  be  linearly  proportional  to  the  number  of  NEs 
and  the  Hurst  parameter  was  assumed  to  be  constant  regardless  of  the  number  of  NEs. 
Due  to  time  and  equipment  constraints,  it  was  not  possible  to  vary  the  number  of  NEs  on 
the  ring  and  to  capture  the  traffic  for  verification.  In  this  respect,  it  would  be  good  to  ac¬ 
quire  two  more  NEs  for  capturing  the  traffic  of  three,  five,  and  six  NEs  on  the  SONET 
ring.  The  utilization  of  the  network  and  the  Hurst  parameter  can  then  be  obtained  for  the 
different  number  of  NEs  on  the  SONET  ring  and  can  verify  if  the  assumptions  made  in 
this  study  are  valid. 

2,  Investigating  the  Traffic  on  the  SDCC 

Again,  in  this  study,  the  network  traffic  was  captured  on  the  IP  network.  Although 
the  captured  traffic  is  representative  of  the  traffic  that  traverses  on  the  SDCC,  there 
maybe  some  traffic  overhead  introduced  by  the  IP  network  that  can  potentially  cause  the 
results  obtained  in  this  study  to  be  inaccurate.  This  was  not  investigated  further  as  the 
equipment  for  capturing  the  traffic  on  the  SDCC  was  not  ready  during  the  course  of  this 
study.  Hopefully,  this  area  can  be  examined  further  with  the  equipment  built  by  Eieuten- 
ant  Matthew  Klobukowski  and  Eieutenant  Commander  Britt  Talbert  for  their  theses. 

3,  Use  of  Cross-vendor’s  EMS 

As  mentioned  in  Chapter  II,  the  SONET  equipment  builders  supply  most  of  the 
EMSs  available  in  the  market,  mainly  for  managing  their  products.  There  is  no  known 
case  of  anyone  using  a  cross-vendor  EMS.  Nevertheless,  SONET  and  the  management 
protocols  are  open  standards.  There  is  no  reason  why  a  cross-vendor  EMS  cannot  be  de- 
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ployed  onto  the  SONET  equipment.  Therefore,  it  would  be  good  if  EMSs  built  by  other 
vendors  ean  be  aequired  and  deployed  in  the  Advaneed  Networking  Eaboratory  for  test¬ 
ing  with  the  Ciseo  equipment.  A  similar  study  ean  also  be  done  to  eompare  the  perform- 
anee  of  eross-vendor  EMSs  against  that  of  Ciseo ’s  EMSs. 

4.  Use  of  Production  Network  Traffic 

The  laboratory  traffie  that  was  eaptured  and  studied  does  not  eontain  user- 
eommand  related  traffie,  as  it  is  diffieult  to  simulate  user-eommands  in  the  laboratory. 
The  impaet  of  user-eommand  related  traffie  was  thus  not  studied.  In  addition,  produetion 
network  traffie  that  eovers  the  different  exeeptions,  faults,  and  alarms,  ete.,  eannot  be 
simulated  under  laboratory  eonditions.  Therefore,  it  would  be  benefieial  if  produetion 
network  traffie  ean  be  aequired  and  studied.  This  would  enable  a  more  aeeurate  analysis 
to  be  performed.  Eurthermore,  a  better  understanding  of  the  management  traffie  ean  be 
aehieved. 
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